[UPDATE] Amazon IVS Low-Latency StreamingでSRT ingestをサポートしました!
はじめに
清水です。AWSのマネージド型ライブストリーミングソリューションであるAmazon Interactive Video Service (Amazon IVS)のLow-Latency StreamingでSRTによるIngestをサポートするようになりました!2024/04/05付けでAWS What's Newに掲載されています。
マネージド型のライブストリーミングソリューションながらも3秒未満の超低遅延を謳い2020/07に登場したAmazon IVS、リリース時からIngestの方式としてRTMPSを採用していました。2023/05にはInsecure ingestとしてRTMPも利用できるようになります。2023/08にはLow-Latency Streamingと呼称するようになりましたが、Streaming Software向けのIngest方式がRTMPベースのものであることに変わりはありませんでした。(RTMPSとRTMPについては、WikipediaのReal Time Messaging Protocolのページによると「“RTMPS - HTTPS を使い、SSL で暗号化されたプロトコル”」ということで、HTTPSとHTTPの違いのようなイメージです。以降、RTMPSとRTMPをまとめて"RTMP"や"RTMPベース"と称します。)
RTMPはIngest方式として長らく使われており、対応しているStreaming Softwareも多いです。IVSリリース当時の2020年ではデファクト・スタンダードのひとつといってもいい状況だったかと思います。しかし、もともとはAdobe Flash向けに開発された技術です。2020年末にはAdobe Flash Playerがサポート終了することに伴い、RTMPも終了するのではないかといった混乱もありました。
そんな中、Ingest方式として注目されてきたプロトコルのひとつがSecure Reliable Transport (SRT)です。ジッターや帯域幅の変化、そしてパケットロスからの影響を最小限に抑えるよう設計されており、信頼性の低いネットワーク上でのストリーミングが改善されています。最近では多くのStreaming Softwareやストリーミングソリューションでも利用可能になってきています。そんな中、Amazon IVS Low-Latency StreamingでもこのSRTが利用可能になったということですね。うれしい!
なお、これまでのRTMPSならびにRTMPのIngestも引き続き利用可能です。(IngestでのRTMPの使用は2024年時点でもまだまだ現役で、HEVCやAV1コーデックのサポートをするという動きもあるようですね。(21年振りにRTMPの新仕様 Enhancing RTMP, FLV について | meteor Tech Blog))Streaming Software側で対応しており限られたネットワーク条件でもビデオ品質を維持したいと行った場合にはSRTを利用、非対応のStreaming Softwareを使用する場合はRTMPベースを使う、といった使い分けをしていくのが良いのかなと思います。
本エントリではIVS Low-Latency Streamingで新たにサポートしたSRT Ingestを使って動画配信をしてみたのでまとめてみたいと思います。
IVS Low-Latency StreamingにSRTでIngestしてみた
IVS Channelの作成
まずはIVSのChannelリソースを作成します。Amazon IVSのマネジメントコンソール、Low-latency > Channelsと進み[Create channel]ボタンを押下します。Channel nameのみを設定、Default configurationでその他の項目もデフォルトのまま、Channelを作成しました。
SRT Ingest用の設定を確認
作成後のChannel詳細ページで画面を下に少しスクロールし、Stream configurationの欄を確認してみましょう。ぱっと見、従来どおりのRTMPS用のIngestの設定しか表示されていませんが……。
Stream configuration欄のOther ingest optionsを展開してみます。SRT endpointとSRT passphraseの項目が現れましたね!Stream keyに加えてこの2つの情報をStreaming Software側に設定するのでメモしておきます。
OBSからSRTでIVSにIngest
IVS ChannelのSRT Ingest用の情報が確認できました。それではLow-Latency Streaming User Guideにならい、実際にOBS StudioからIVSにSRTで映像を打ち上げてみます。以下ドキュメントの「Streaming with OBS Studio using SRT」を参考に進めました。(Document Historyによると、2024/04/04付で更新がされたそうです。)
OBSの[設定]から[配信]の設定箇所を開きます。[サービス]で[カスタム…]を選択すると、[サーバー]情報が入力できるようになりますね。ここに先ほど確認したSRT endpointなどの情報を入力しますが、以下の形式に文字列を連結する必要があるようです。
[SRT endpoint]?streamid=[Stream key]&passphrase=[SRT passphrase]
srt
で始まるURLの形式にして、クエリ文字列でstreamid
とpassphrase
を指定するかたちですね。[ストリームキー]の欄は使用しません。具体的には以下のような形式になります。
srt://xxxx.srt.live-video.net:9000?streamid=sk_ap-northeast-1_xxxxxx&passphrase=xxxxxxxx
この文字列を[サーバー]欄に入力します。以上でIngest先の設定は完了です。
さらにUserGuideにならい、[出力]の設定項目のエンコーダ設定の[キーフレーム間隔]の値を2秒に設定しておきました。
あとは従来のOBS操作と変わらず、[配信開始]ボタンでOBSからIVSへ、SRTでのIngestがはじまります。
SRTでIVSにIngestした映像の視聴
Ingest後の動画の視聴は従来と変わりません。AWSマネジメントコンソールでも視聴確認はできますが、今回は以下のようなAmazon IVS Player SDKを利用したHTMLページを作成してWebサーバ経由で参照しました。PLAYBACK_URL
に指定するURLは従来通り、AWSマネジメントコンソールのChannel詳細ページ、Playback configurationの項目から確認できるPlayback URLです。
<html> <head> <title>ivs-srt-ingest-channel</title> <style> video { height: 100%; width: 100%; left: 0; top: 0; position: fixed; } </style> </head> <body> <video id="video-player" playsinline controls></video> <script src="https://player.live-video.net/1.26.0/amazon-ivs-player.min.js"></script> <script> var PLAYBACK_URL = "https://xxxx.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.WHxxxxxxxxxx.m3u8" if (IVSPlayer.isPlayerSupported) { const player = IVSPlayer.create(); player.attachHTMLVideoElement(document.getElementById('video-player')); player.load(PLAYBACK_URL); player.play(); } </script> </body> </html>
SRTでIngestしている映像が、視聴側のPlayerで確認できました!
まとめ
Amazon Interactive Video Service (Amazon IVS)のLow-Latency Streamingで、次世代の映像伝送プロトコルともいわれるSRT: Secure Reliable TransportをIngest方式としてサポートしたアップデートについてお伝えしました!ネットワークが不安定な場所から映像を打ち上げる場合の信頼性の向上が期待できます。最近ではSRTをサポートしたStreaming Softwareやストリーミングソリューションなども増えてきたので、Amazon IVSも早くサポートしないかなと待ち望んでいた方も多いのではないでしょうか。
SRT Ingestの使用について、IVS Channelリソース側の使用方法としては従来と同様です。Streaming Software側に設定する際にはSRT endpointがRTMPSとは異なるドメインであること、SRT passphraseが別途必要なこと、URLにクエリ文字列のようなかたちで指定することなどに注意しましょう。なおIVS Channel側がSRT Listenerとして動作します。Streaming Software側はSRT Callerになるかたちですね。(SRTプロトコルのListenerとCallerの違いを整理してみた | DevelopersIO)
従来までのRTMPSと比べて遅延に違いは生じるのかとか、同じChannelに対してRTMPSとSRTを交互にIngestしても問題ないのかとか、詳細部分で気になる点はいくつかあるのですが、まずは私も待ち望んでいたSRT Ingestサポートのアップデートについて速報としてお届けしました。